Would you lock the front door and leave the back door wide open? What about safely parking the car under a shade tree and leaving the keys in the ignition? This kind of half-safe security practice is all too common among system administrators. They have become lazy in the implementation of even the basic security features and cave to the pressure to get the databases running as quickly as possible. Corners are cut and security issues pushed to the background. Fortunately in many cases, administrators get lucky and the hackers overlook their oversights. But too often the luck runs out.

Database security issues have been flooding the media and Internet news-wires. First there was the Slammer worm and most recently criminals accessing over 8 million credit card numbers. The time has come to take a stand against the hackers of the world by making databases more secure.

Companies seem to have a single focus in mind: Software Security. So much emphasis is put upon this single portion of security that the system administrators loose sight of the big picture. The big picture is of course, "Without a structured security hierarchy any basic security policy will fail!"

Lack of common security protocols leaves system administrators are left to their own accord: bound to the creation, management and the security of systems, but with little or no oversight by a higher security administrator. This raises the following questions:

Database administrators must also protect the system from unseen opponents. These cowardly "opponents" sneak into a system, cause havoc, and then quietly leave. Identifying these assailants is difficult; catching them, near impossible.

A wise man philosopher (Zhuge Laing) once said "you must know yourself, know your enemy and you will never lose the war". Suppose you are the proud creator of a fully functional database. In order to keep it running you must protect your creation from:

• Competitors looking for that extra edge.
• Malicious insiders harboring ill will toward your company -- the vast majority of attacks on SQL data.
• Internet hackers looking for another thrill.

Multi-user mainframe operating systems are designed to be used by many people at once, and so have to be able to distinguish between these different users in a secure and foolproof manner. In addition, the operating system must to be able to control the access each user had to features and functions of the system. To this end security features such as password controls, privileges, user identification codes, protection masks and all manner of other devices were employed to make sure that data was secure.

Basically database security can be broken down into the following key points of interest. (click the blue hyperlinks to learn more)

 The most reliable solution for protecting sensitive data is to establish a procedure to implement strong encryption at the application level, outside the SQL DBMS. Encryption protects data in all cases: network intrusion, database dump, theft of the hard drive.

This application-based approach does have disadvantages, however:

• New development efforts required (strong encryption). Qualified DBAs only, please.
• Applications must be rewritten. And we know how much of a hassle that can be.
• New test sets to create before deployment. It is of the utmost importance to test the security features before exposing them to the harsh realities of life.

But, it does not always have to be such a struggle. Software applications like SafeJDBC virtually eliminates these disadvantages by adding an application layer for the SQL data encryption, with no changes to existing code and no new development efforts required.

In many ways databases are a ticking time bomb. However an explosion can be prevented. One just needs to take the time to implement security measures. The question is: Will you?

Clear as mud? Here are some additional references to clear up the matter.

Now that you know everything, how about answering a few questions:

1. The majority of attacks on SQL data come from:

1. Hackers looking for a little fun
2. Competitors trying to find blackmail material
3. Insiders harboring ill will toward to company
4. None of the above

1. The rush to get databases up and running pushed security to the background
2. DBAs are seldom supervised by a higher security administrator
3. So much emphasis is put on software security that other issues are overlooked
4. All of the above

1. permissions
2. okays
3. duties
4. consents